Managing diagnostic information

ABSTRACT

A computer program product for managing diagnostic information is disclosed. The computer program product may include creating a data space in volatile memory. The data space may be configured to collect a selected diagnostic information. The selected diagnostic information may include a first diagnostic information from a first source and a second diagnostic information from a second source. The computer program product may include collecting in the data space the selected diagnostic information. The computer program product may include releasing from the data space at least a portion of the selected diagnostic information in response to a triggering event.

TECHNICAL FIELD

This disclosure relates generally to monitoring computer systems and,more particularly, relates to diagnostic information.

BACKGROUND

Diagnostic information associated with an error event may be gathered.The diagnostic information may be utilized in an attempt to determine acause of the error event. For example, a user may examine diagnosticinformation such as system records for data related to the error event.Error events may lead to integrity problems, application outages, orexpend resources. As such, significant costs may be associated witherror events.

SUMMARY

Aspects of the disclosure may include a computer program product formanaging diagnostic information. The computer program product mayinclude creating a data space in volatile memory. The data space may beconfigured to collect a selected diagnostic information. The selecteddiagnostic information may include a first diagnostic information from afirst source and a second diagnostic information from a second source.The computer program product may include collecting in the data spacethe selected diagnostic information. The computer program product mayinclude releasing from the data space at least a portion of the selecteddiagnostic information in response to a triggering event.

Aspects of the disclosure may include the selected diagnosticinformation being a subset of an all-inclusive diagnostic information ofthe first and second sources. The selected diagnostic information mayinclude an intermixing of the first diagnostic information and thesecond diagnostic information. The triggering event may include an errorevent. Releasing from the data space at least a portion of the selecteddiagnostic information may include dumping from the data space at leasta portion of the selected diagnostic information. The triggering eventmay include a collection threshold event. Releasing from the data spaceat least a portion of the selected diagnostic information may includewrapping in the data space at least a portion of the selected diagnosticinformation. Aspects of the disclosure may collect in the memorydiagnostic information for time periods before, during, and after errorevents. Aspects of the disclosure may be beneficial to reducing costsassociated with error events.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example network architecture according to anembodiment;

FIG. 2 illustrates an example storage system containing an array ofstorage devices according to an embodiment;

FIG. 3 is a flowchart illustrating an operation for managing diagnosticinformation according to an embodiment; and

FIG. 4 shows modules of a system implementing an operation according toan embodiment.

DETAILED DESCRIPTION

Computer systems may be monitored and performance may be analyzed.Diagnostic information may exist that is associated with an error event.The diagnostic information may be gathered. The diagnostic informationmay be utilized in an attempt to determine a cause of the error event.The cause of the error event may be avoided in future cases. Costsassociated with error events may be reduced.

It may be challenging to gather diagnostic information for error events.The diagnostic information may be desired to be gathered from multiplesources. The diagnostic information may be captured at varying times.Saving the diagnostic information to disk may expend resources. If theerror events occur infrequently or unpredictably, capturingdocumentation may be particularly challenging. Users do not want toexperience error events, and certainly do not want to experience errorevents multiple times just to gather documentation. Capturing thedesired documentation from multiple sources in case of an error eventmay be beneficial to reducing costs associated with error events.

Aspects of the disclosure may include managing diagnostic information. Adata space may be created. The data space may be created in a memory(e.g., volatile memory). The memory may be configured to collect aselected diagnostic information. The selected diagnostic information mayinclude a first diagnostic information from a first source. The selecteddiagnostic information may include a second diagnostic information froma second source. The selected diagnostic information may be collected inthe data space.

Aspects of the disclosure may include releasing from the data space atleast a portion of the selected diagnostic information. Such release mayoccur in response to a triggering event. The triggering event mayinclude an error event. Releasing from the data space at least a portionof the selected diagnostic information may include dumping from the dataspace at least a portion of the selected diagnostic information. Thetriggering event may include a collection threshold event. Releasingfrom the data space at least a portion of the selected diagnosticinformation may include wrapping in the data space at least a portion ofthe selected diagnostic information.

Aspects of the disclosure may include the selected diagnosticinformation being a subset of an all-inclusive diagnostic information ofthe first and second sources. The selected diagnostic information mayinclude an intermixing of the first diagnostic information and thesecond diagnostic information. The selected diagnostic information mayinclude at least one of error information, data from a data set,metadata about a data set, system data, application history, performanceinformation, and input-output (I/O) tracing. In particular, the selecteddiagnostic information may include a channel command or a supervisorcall (SVC). Aspects of the disclosure may collect in the memorydiagnostic information for time periods before, during, and after errorevents. Aspects of the disclosure may be beneficial to reducing costsassociated with error events.

FIG. 1 illustrates an example network architecture 100 according to anembodiment. The network architecture 100 is presented to show oneexample of an environment where a system, method, and computer programproduct in accordance with the disclosure may be implemented. Thenetwork architecture 100 is presented only by way of example and is notintended to be limiting. The system and methods disclosed herein may beapplicable to a wide variety of different computers, servers, storagedevices, and network architectures, in addition to the networkarchitecture 100 shown.

As shown, the network architecture 100 includes one or more computers102, 106 interconnected by a network 104. The network 104 may include,for example, a local-area-network (LAN), a wide-area-network (WAN), theInternet, an intranet, or the like. In certain embodiments, thecomputers 102, 106 may include both client computers 102 and servercomputers 106 (also referred to herein as “host systems” 106). Ingeneral, client computers 102 may initiate communication sessions,whereas server computers 106 may wait for requests from the clientcomputers 102. In certain embodiments, the computers 102 and/or servers106 may connect to one or more internal or external direct-attachedstorage systems 112 (e.g., arrays of hard-disk drives, solid-statedrives, tape drives, etc.). These computers 102, 106 and direct-attachedstorage systems 112 may communicate using protocols such as ATA, SATA,SCSI, SAS, Fibre Channel, or the like. One or more of the storagesystems 112 may contain storage pools that may benefit from managementtechniques of the disclosure.

The network architecture 100 may, in certain embodiments, include astorage network 108 behind the servers 106, such as astorage-area-network (SAN) or a LAN (e.g., when using network-attachedstorage). This network 108 may connect the servers 106 to one or morestorage systems 110, such as arrays 110 a of hard-disk drives orsolid-state drives, tape libraries 110 b, individual hard-disk drives110 c or solid-state drives 110 c, tape drives 110 d, CD-ROM libraries,or the like. To access a storage system 110, a host system 106 maycommunicate over physical connections from one or more ports on the host106 to one or more ports on the storage system 110. A connection may bethrough a switch, fabric, direct connection, or the like. In certainembodiments, the servers 106 and storage systems 110 may communicateusing a networking standard such as Fibre Channel (FC). One or more ofthe storage systems 110 may contain storage pools that may benefit frommanagement techniques according to the disclosure.

FIG. 2 illustrates an example storage system 110 a containing an arrayof storage devices 204 (e.g., hard-disk drives and/or solid-statedrives) according to an embodiment. The internal components of thestorage system 110 a are shown in accordance with the disclosure and maybe used to manage diagnostic information associated with such a storagesystem 110 a. Nevertheless, management techniques according to thedisclosure may also be implemented within other storage systems 110,112. As shown, the storage system 110 a includes a storage controller200, one or more switches 202, and one or more storage devices 204, suchas hard-disk drives or solid-state drives (e.g., flash-memory-baseddrives). The storage controller 200 may enable one or more hosts 106(e.g., open system and/or mainframe servers 106) to access data storedin the one or more storage devices 204.

As shown in FIG. 2, the storage controller 200 includes one or moreservers 206. The storage controller 200 may also include host adapters208 and device adapters 210 to connect the storage controller 200 tohost devices 106 and storage devices 204, respectively. Multiple servers206 a, 206 b may provide redundancy to ensure that data is alwaysavailable to connected hosts 106. Thus, when one server 206 a fails, theother server 206 b may remain functional to ensure that I/O is able tocontinue between the hosts 106 and the storage devices 204. This processmay be referred to as a “failover.”

Particular enterprise storage systems may have a storage system 110 ahaving an architecture similar to that illustrated in FIG. 2. Particularenterprise storage systems may include a high-performance, high-capacitystorage controller providing disk storage that is designed to supportcontinuous operations. Particular enterprise storage systems may useservers 206 a, 206 b, which may be integrated with a virtualizationengine technology. Nevertheless, management techniques according to thedisclosure are not limited to any specific enterprise storage system 110a, but may be implemented in any comparable or analogous storage system110 regardless of the manufacturer, product name, or components orcomponent names associated with the storage system 110. Any storagesystem 110 that could benefit from management techniques according tothe disclosure is deemed to fall within the scope of the disclosure.Thus, the enterprise storage system shown is presented only by way ofexample and is not intended to be limiting.

In selected embodiments, each server 206 includes one or more processors212 (e.g., n-way symmetric multiprocessors) and memory 214. The memory214 may include volatile memory (e.g., RAM) as well as non-volatilememory (e.g., ROM, EPROM, EEPROM, hard disks, flash memory, etc.). Thevolatile memory and non-volatile memory may store software modules thatrun on the processor(s) 212 and are used to access data in the storagedevices 204. The servers 206 may host at least one instance of thesesoftware modules. These software modules may manage all read and writerequests to logical volumes in the storage devices 204.

FIG. 3 is a flowchart illustrating an operation 300 for managingdiagnostic information according to an embodiment. Diagnosticinformation may include data related to error events. Operation 300 maybe beneficial to reducing costs associated with error events. Operation300 may begin at block 301. A data space may be created (e.g.,established) at block 310. In embodiments, the data space may beconsidered to be at least one of centralized, collective, combined,common, community, gathered, merged, pooled, and shared. The data spacemay be created in a memory (e.g., volatile memory). The memory may beconfigured to collect selected diagnostic information.

The selected diagnostic information may include a first diagnosticinformation from a first source. The selected diagnostic information mayinclude a second diagnostic information from a second source. Inembodiments, the first and second sources may include at least one of anapplication, a component, a job, a program, a task, and a user activity.The selected diagnostic information may be collected in the data spaceat block 320.

In embodiments, the selected diagnostic information may include anintermixing of the first diagnostic information and the seconddiagnostic information. Intermixing may include data of the sourcesbeing merged, for example, by timestamps and related functions.Therefore, for instance, processes occurring together, at substantiallythe same time, or in a time window preceding error events may beanalyzed. For example, a cause of a resource contention error (e.g.,error due to a conflict over access to a shared resource) may be moreapparent or more quickly diagnosed with the first and second diagnosticinformation in the data space which is shared by multiple sources andmay include intermixed data. In such example, the data is not spreadover multiple disks but is instead in the memory. Also in such example,the intermixed data may clarify the nature of the conflict betweenresources.

In embodiments, the selected diagnostic information may be a subset ofan all-inclusive diagnostic information of the first and second sources.The subset may include the selected diagnostic information consisting ofdiagnostic elements smaller in quantity or quality than theall-inclusive diagnostic information. The all-inclusive diagnosticinformation may include all diagnostic information (e.g., all datarelated to error events) of both the first source and the second source.The subset of the all-inclusive diagnostic information may include datavital, essential, or merely helpful to understanding events related tothe first and second sources.

In embodiments, the selected diagnostic information may include, forexample, at least one of error information, data from a data set,metadata about a data set, system data, application history, performanceinformation, and input-output (I/O) tracing. For instance, performanceinformation may include resource contention. In particular embodiments,the selected diagnostic information may include a channel command. Thechannel command may be a word instructing an action. The channel commandmay be related to (e.g., recorded by) a generalized trace facility(GTF). In particular embodiments, the selected diagnostic informationmay include a supervisor call (SVC). The SVC may include a processorinstruction directing the processor to pass control of a computer to asupervisor program of an operating system. The SVC may include a requestfor a specific operating system service from an application program orpart of the operating system. The selected diagnostic information mayinclude at least one of clear subchannel operations, externalinterruptions, halt subchannel operations, I/O interruptions,program-controlled interruptions, non-program-controlled interruptions,end of sense interruptions, modify subchannel operations, recoveryroutines, start subchannel operations, resume channel operations, andSVC interruptions.

Operation 300 may collect in the memory diagnostic information for timeperiods before, during, and after error events. In embodiments,collecting may include at least one of capturing, confining, corralling,detaining, gathering, holding, preserving, receiving, retaining,seizing, storing, and writing. The collecting may be a short-termstoring. The collecting may be an ongoing capturing. The collecting maybe a continual writing. A variety of combinations of the collecting arecontemplated (e.g., ongoing capturing, continual gathering).

At least a portion of the selected diagnostic information may bereleased from the data space at block 330. Such release may occur inresponse to a triggering event. The triggering event may include anerror event. In embodiments, the error event may include an actual error(e.g., access to resource improperly locked) or a perceived error (e.g.,access to resource exceeding a temporal latency threshold). For example,the error event may include at least one of an error occurring,detecting an error, detecting a potential error, and a potential erroroccurring. The triggering event may include a collection thresholdevent. In embodiments, the collection threshold event may includereaching a collection threshold value. The collection threshold valuemay be an amount of data space or memory allocated to collect theselected diagnostic information. For example, the collection thresholdvalue may be reached when the data space runs out of room to collectfurther data. The data space may run out of room to collect further dataafter, for instance, five seconds or one-hundred kilobytes ofcollection.

In embodiments, releasing may include at least one of copying, deleting,dumping, erasing, reading, recording, saving, and wrapping. Releasingmay or may not clear the data space. In embodiments, releasing from thedata space at least a portion of the selected diagnostic information mayinclude dumping from the data space at least a portion of the selecteddiagnostic information. Dumping may include saving off in a differentdata space. Dumping may include recording data elsewhere (e.g., disk,nonvolatile memory) for use in subsequent problem analysis.

In embodiments, releasing from the data space at least a portion of theselected diagnostic information may include wrapping in the data spaceat least a portion of the selected diagnostic information. Wrapping mayinclude selectively overwriting. Selectively overwriting may includewriting over a first portion of the selected diagnostic informationdeemed to be a lower priority than a second portion of the selecteddiagnostic information. The first portion of the selected diagnosticinformation in such case may no longer exist subsequent to theoverwriting. Wrapping may occur in a first-in-first-out (FIFO) order.

Operation 300 may conclude at block 399. Operation 300 may providehistorical data (and data from related sources) leading up to errorevents. Multiple sources may be able to record information associatedwith error events to a common data space. Operation 300 may gatherinformation related to error events. Related information may be groupedtogether in the common data space. Operation 300 may be beneficial toreducing costs associated with error events.

For example, when an I/O error takes place, I/O drivers may record asubset of selected diagnostic information that may be recorded in atypical GTF trace. Selected diagnostic information may be written tomemory rather than disk, and a smaller amount of data may be recorded,which may decrease performance impact. When the collection thresholdevent occurs, trace entries may wrap. When the error event occurs,dumping or saving off in a different data space may occur. For anon-retryable event, the data may be dumped to disk. For a retryableerror, the data may be copied to a different data space where it is helduntil the retry events reach a retry threshold value or the I/Osucceeds. If the retry is successful, the data may be discarded ordumped, depending on a user setting. If the retryable error continues tofail, both the original error and the retried error may be dumped. Inaddition, when an abnormal end occurs in a primary data space of thesource, the associated selected diagnostic information in the data spacemay be dumped. As another example, when an SVC is made and a jobabnormally ends, the data space may include an SVC history of SVCsissued leading up to the time of the failure. Other possibilities areconsidered.

FIG. 4 shows modules of a system implementing operation 300 according toan embodiment. In embodiments, operation 300 may be implemented in theform of one or more modules. These modules may be implemented inhardware, software or firmware executable on hardware, or a combinationthereof. For example, module functionality that may occur in a hostsystem 106 may actually be implemented in a remote system 110 and viceversa. Other functionality may be distributed across the host system 106and the remote system 110.

A host system 106 may include a diagnostic information management module400. The diagnostic information management module 400 may managediagnostic information. The diagnostic information management module 400may include a data space creation module 410, a selected diagnosticinformation module 415, a collection module 420, a release module 430,and a triggering event module 435. The remote system 110 may have a dataset 440 comprising storage volumes 441 adapted to have storage data 442.The remote system 110 may have a memory 450. The memory 450 may bevolatile memory. The memory 450 may include a data space 455. Inembodiments, the data space 455 may be considered to be at least one ofcentralized, collective, combined, common, community, gathered, merged,pooled, and shared.

The data space creation module 410 may create (e.g., establish) the dataspace 455 in the memory 450 in an embodiment. The memory 450 may beconfigured to collect a selected diagnostic information. The selecteddiagnostic information module 415 may have the selected diagnosticinformation including a first diagnostic information from a first sourceand a second diagnostic information from a second source. Inembodiments, the first and second sources may include at least one of anapplication, a component, a job, a program, a task, and a user activity.The selected diagnostic information and embodiments thereof may besimilar or the same as described above relating to FIG. 3.

The collection module 420 may collect in the data space 455 the selecteddiagnostic information. The collection module 420 may collect in thememory diagnostic information for time periods before, during, and aftererror events. In embodiments, collecting may include at least one ofcapturing, confining, corralling, detaining, gathering, holding,preserving, receiving, retaining, seizing, storing, and writing. Thecollecting may be a short-term storing. The collecting may be an ongoingcapturing. The collecting may be a continual writing. A variety ofcombinations of the collecting are contemplated (e.g., ongoingcapturing, continual gathering).

The release module 430 may release from the data space 455 at least aportion of the selected diagnostic information in response to atriggering event. Such release may occur in response to a triggeringevent. The triggering event module 435 may characterize the triggeringevent. The triggering event may include an error event. In embodiments,the error event may include an actual error (e.g., access to resourceimproperly locked) or a perceived error (e.g., access to resourceexceeding a temporal latency threshold). For example, the error eventmay include at least one of an error occurring, detecting an error,detecting a potential error, and a potential error occurring. Thetriggering event may include a collection threshold event. Inembodiments, the collection threshold event may include reaching acollection threshold value. The collection threshold value may be anamount of data space or memory allocated to collect the selecteddiagnostic information. For example, the collection threshold value maybe reached when the data space runs out of room to collect further data.

In embodiments, releasing performed by the release module 430 mayinclude at least one of copying, deleting, dumping, erasing, reading,recording, saving, and wrapping. Releasing may or may not clear the dataspace 455. In embodiments, releasing from the data space 455 at least aportion of the selected diagnostic information may include dumping fromthe data space at least a portion of the selected diagnosticinformation. Dumping may include saving off in a different data space.Dumping may include recording data elsewhere (e.g., disk, nonvolatilememory) for use in subsequent problem analysis.

In embodiments, releasing from the data space 455 at least a portion ofthe selected diagnostic information may include wrapping in the dataspace 455 at least a portion of the selected diagnostic information.Wrapping may include selectively overwriting. Selectively overwritingmay include writing over a first portion of the selected diagnosticinformation deemed to be a lower priority than a second portion of theselected diagnostic information. The first portion of the selecteddiagnostic information in such case may no longer exist subsequent tothe overwriting. Wrapping may occur in a first-in-first-out (FIFO)order.

The diagnostic information management module 400 may provide historicaldata (and data from related sources) leading up to error events.Multiple sources may be able to record information associated with errorevents to the data space 455. The diagnostic information managementmodule 400 may gather information related to error events. Relatedinformation may be grouped together in the data space 455. Thediagnostic information management module 400 may be beneficial toreducing costs associated with error events.

In addition to embodiments described above, other embodiments havingfewer operational steps, more operational steps, or differentoperational steps are contemplated. Also, some embodiments may performsome or all of the above operational steps in a different order. Themodules are listed illustratively according to an embodiment and are notmeant to indicate necessity of a particular module or exclusivity ofother potential modules.

In the foregoing, reference is made to various embodiments. It should beunderstood, however, that this disclosure is not limited to thespecifically described embodiments. Instead, any combination of thedescribed features and elements, whether related to differentembodiments or not, is contemplated to implement and practice thisdisclosure. Many modifications and variations may be apparent to thoseof ordinary skill in the art without departing from the scope and spiritof the described embodiments. Furthermore, although embodiments of thisdisclosure may achieve advantages over other possible solutions or overthe prior art, whether or not a particular advantage is achieved by agiven embodiment is not limiting of this disclosure. Thus, the describedaspects, features, embodiments, and advantages are merely illustrativeand are not considered elements or limitations of the appended claimsexcept where explicitly recited in a claim(s).

As will be appreciated by one skilled in the art, aspects of the presentdisclosure may be embodied as a system, method, or computer programproduct. Accordingly, aspects of the present disclosure may take theform of an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.), or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module,” or “system.”Furthermore, aspects of the present disclosure may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination thereof. More specificexamples (a non-exhaustive list) of the computer readable storage mediumwould include the following: an electrical connection having one or morewires, a portable computer diskette, a hard disk, a random access memory(RAM), a read-only memory (ROM), an erasable programmable read-onlymemory (EPROM or Flash memory), an optical fiber, a portable compactdisc read-only memory (CD-ROM), an optical storage device, a magneticstorage device, or any suitable combination thereof. In the context ofthis disclosure, a computer readable storage medium may be any tangiblemedium that can contain, or store, a program for use by or in connectionwith an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wire line, optical fiber cable, RF, etc., or any suitable combinationthereof.

Computer program code for carrying out operations for aspects of thepresent disclosure may be written in any combination of one or moreprogramming languages, including: an object oriented programminglanguage such as Java, Smalltalk, C++, or the like; and conventionalprocedural programming languages, such as the “C” programming languageor similar programming languages. The program code may execute asspecifically described herein. In addition, the program code may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer, or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider).

Aspects of the present disclosure have been described with reference toflowchart illustrations, block diagrams, or both, of methods,apparatuses (systems), and computer program products according toembodiments of this disclosure. It will be understood that each block ofthe flowchart illustrations or block diagrams, and combinations ofblocks in the flowchart illustrations or block diagrams, can beimplemented by computer program instructions. These computer programinstructions may be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing the functionsor acts specified in the flowchart or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function or act specified in the flowchart or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus, or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions or acts specified in the flowchart or blockdiagram block or blocks.

Embodiments according to this disclosure may be provided to end-usersthrough a cloud-computing infrastructure. Cloud computing generallyrefers to the provision of scalable computing resources as a serviceover a network. More formally, cloud computing may be defined as acomputing capability that provides an abstraction between the computingresource and its underlying technical architecture (e.g., servers,storage, networks), enabling convenient, on-demand network access to ashared pool of configurable computing resources that can be rapidlyprovisioned and released with minimal management effort or serviceprovider interaction. Thus, cloud computing allows a user to accessvirtual computing resources (e.g., storage, data, applications, and evencomplete virtualized computing systems) in “the cloud,” without regardfor the underlying physical systems (or locations of those systems) usedto provide the computing resources.

Typically, cloud-computing resources are provided to a user on apay-per-use basis, where users are charged only for the computingresources actually used (e.g., an amount of storage space used by a useror a number of virtualized systems instantiated by the user). A user canaccess any of the resources that reside in the cloud at any time, andfrom anywhere across the Internet. In context of the present disclosure,a user may access applications or related data available in the cloud.For example, the nodes used to create a stream computing application maybe virtual machines hosted by a cloud service provider. Doing so allowsa user to access this information from any computing system attached toa network connected to the cloud (e.g., the Internet).

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams or flowchart illustration, andcombinations of blocks in the block diagrams or flowchart illustration,can be implemented by special purpose hardware-based systems thatperform the specified functions or acts, or combinations of specialpurpose hardware and computer instructions.

While the foregoing is directed to exemplary embodiments, other andfurther embodiments of the disclosure may be devised without departingfrom the basic scope thereof, and the scope thereof is determined by theclaims that follow.

What is claimed is:
 1. A non-transitory computer program product formanaging diagnostic information, the computer program product comprisinga computer readable storage medium having program instructions embodiedtherewith, wherein the computer readable storage medium is not atransitory signal per se, the program instructions to cause: allocatinga data space in a volatile memory to store a selected diagnosticinformation, the selected diagnostic information including a firstdiagnostic information from a first source and a second diagnosticinformation from a second source, the selected diagnostic informationbeing a subset of information recorded by a generalized trace facilityrecording events of the first and second sources; collecting in the dataspace the selected diagnostic information, the collecting including: anintermixing of the first diagnostic information and the seconddiagnostic information during a time window preceding an error event,and a wrapping in the data space of at least a portion of the selecteddiagnostic information when a collection threshold amount of the dataspace is reached; and dumping from the data space to a non-volatilememory at least a portion of the selected diagnostic information inresponse to the error event.
 2. The computer program product of claim 1,wherein the first source is an application program and the second sourceis an input/output component.
 3. The computer program product of claim1, wherein the selected diagnostic information includes a third sourceand a fourth source, and the first source is a first server, the secondsource is a second server, the third source is a host adapter, and thefourth source is a device adapter.
 4. The computer program product ofclaim 1, wherein the error event includes an improper lock of aresource.
 5. The computer program product of claim 1, wherein the errorevent includes an attempt to access a resource exceeding a latencythreshold.
 6. The computer program product of claim 1, wherein theselected diagnostic information includes a first interrupt by the firstsource and a second interrupt by the second source.
 7. The computerprogram product of claim 1, wherein the selected diagnostic informationincludes a first application history of the first source and a secondapplication history of the second source.
 8. The computer programproduct of claim 1, wherein the selected diagnostic information includesa first channel command by the first source and a second channel commandby the second source.
 9. The computer program product of claim 1,wherein the selected diagnostic information includes a first supervisorcall (SVC) by the first source and a second SVC by the second source.